/*
 *  (C) LuoZH   2011-07-15
 *      实际上今天是七月十五还是十四还是什么的,不过大体上就是那么个时间.
 *      嗯哼,终于要开始写传说中的IPC了,这个我本来打算是在进程调度后面写的,但是写
 *  进程调度的时候用到malloc,这个东西我还没有一个清晰的策略,贸然行事担心破坏了前
 *  看起来比较优美的结构.
 *      消息机制使用系统调用的形似来完成,中断号定义在kernel.h头文件里,SYS_CALL_\
 *  NUM,该值通常情况下是0x80,和linux的一致,但是系统其实只是使用很少的系统调用,本
 *  来我打算使用0x79,以避开和linux冲突,因为我考虑如果这个系统有起色的话,可能要实
 *  现linux的系统调用以使用linux的程序,当然这个系统调用其实只是一个虚拟的系统调
 *  其内部只是简单发送跟这个系统调用相同功能的消息而已,不过我又想,这样会有两个系
 *  统调用,不是很好,于是我想,干脆直接使用linux的0x80,然后将功能号使用一个linux长
 *  期内不会使用的功能号好了.
 */
#include    <gmL/kernel.h>
#include    <gmL/thread.h>
#include    <gmL/msg.h>
/*
 *      消息传递采用了另一种方式,跟Minix有很大的差别,消息本质上只是一个整数,类似
 *  于linux的系统调用.Minix采用的是即时通信制,也就是进程自己互相通信,类似QQ,是点
 *  对点.这种通信效率我不好评价,感觉很不错.但是我更喜欢另一种通信,就是类似现在的
 *  WEB站点一样,采用服务制,进程分为服务进程和用户进程,用户进程像内核申请服务,但
 *  是它不知道谁为她服务,它只需得到服务就行,而服务进程,启动时跟内核打个招呼,说,
 *  老兄,关于XX这件事就交给我吧.这样做有一个好处,就是如果服务进程服务不够周到,比
 *  把两块钱的避孕套买到200块钱,而不提供售后服务...,嗯哼,我们只需将给服务员替换
 *  掉,而完全不会映像其他部分.而顾客完全不知道服务对象的变化,另一个好处就是,这
 *  样就不会出现linux那种复杂的依赖关系.同一个程序,如果移到另一个机器上,只要对方
 *  也提供这种服务,你就可以顺利运行.而不用带上这台机器的服务员一起到对方的餐厅去
 *  用餐,虽然对方的服务员可能没有这家的漂亮.不过这样做好像会带来不小的对性能的
 *  损耗.
 */
/*
 *  -------------------需用malloc进行重新构造的部分----------------
 */
//这是一个系统调用,将msg服务交给thread,并把入驻TASK的顾客队列
#define     MSG_LIST_ADDR   0x114000
pid_t * const msg_list=(pid_t *)MSG_LIST_ADDR;
int sys_reg_serve(pid_t pid,int msg){
    msg_list[msg]=pid;
    return  0;
}
/*
 *      有必要先阐明我的思想,否则无法继续进行了,服务进程注册服务进入睡眠状态,
 *  当内核接受到发送给服务进程的信号的时候,将该信息放入服务进程的消息队列,然后
 *  唤醒服务进程,服务完成后,服务进程将结果返回给系统,系统将结果返回给申请进程.
 *  如果服务进程没有信号要处理,转入睡眠.
 *
 */
int sys_send(int msg){
    thread_list[msg_list[msg]].msg.msg[0]=msg;
    return 0;
}
void sork_msg(int *msg){
    for(int i=0;i<MSG_LEN-1;i++){
        msg[i]=msg[i+1];
    }
}
int sys_receiv(void){
    int msg;
    msg=thread_list[cur_thread].msg.msg[0];
    sork_msg(thread_list[cur_thread].msg.msg);
    return msg;
}
/*
 *  (C) LuoZH   2011-07-15
 *      实际上今天是七月十五还是十四还是什么的,不过大体上就是那么个时间.
 *      嗯哼,终于要开始写传说中的IPC了,这个我本来打算是在进程调度后面写的,但是写
 *  进程调度的时候用到malloc,这个东西我还没有一个清晰的策略,贸然行事担心破坏了前
 *  看起来比较优美的结构.
 *      消息机制使用系统调用的形似来完成,中断号定义在kernel.h头文件里,SYS_CALL_\
 *  NUM,该值通常情况下是0x80,和linux的一致,但是系统其实只是使用很少的系统调用,本
 *  来我打算使用0x79,以避开和linux冲突,因为我考虑如果这个系统有起色的话,可能要实
 *  现linux的系统调用以使用linux的程序,当然这个系统调用其实只是一个虚拟的系统调
 *  其内部只是简单发送跟这个系统调用相同功能的消息而已,不过我又想,这样会有两个系
 *  统调用,不是很好,于是我想,干脆直接使用linux的0x80,然后将功能号使用一个linux长
 *  期内不会使用的功能号好了.
 */
#include    <gmL/kernel.h>
#include    <gmL/thread.h>
#include    <gmL/msg.h>
/*
 *      消息传递采用了另一种方式,跟Minix有很大的差别,消息本质上只是一个整数,类似
 *  于linux的系统调用.Minix采用的是即时通信制,也就是进程自己互相通信,类似QQ,是点
 *  对点.这种通信效率我不好评价,感觉很不错.但是我更喜欢另一种通信,就是类似现在的
 *  WEB站点一样,采用服务制,进程分为服务进程和用户进程,用户进程像内核申请服务,但
 *  是它不知道谁为她服务,它只需得到服务就行,而服务进程,启动时跟内核打个招呼,说,
 *  老兄,关于XX这件事就交给我吧.这样做有一个好处,就是如果服务进程服务不够周到,比
 *  把两块钱的避孕套买到200块钱,而不提供售后服务...,嗯哼,我们只需将给服务员替换
 *  掉,而完全不会映像其他部分.而顾客完全不知道服务对象的变化,另一个好处就是,这
 *  样就不会出现linux那种复杂的依赖关系.同一个程序,如果移到另一个机器上,只要对方
 *  也提供这种服务,你就可以顺利运行.而不用带上这台机器的服务员一起到对方的餐厅去
 *  用餐,虽然对方的服务员可能没有这家的漂亮.不过这样做好像会带来不小的对性能的
 *  损耗.
 */
/*
 *  -------------------需用malloc进行重新构造的部分----------------
 */
//这是一个系统调用,将msg服务交给thread,并把入驻TASK的顾客队列
#define     MSG_LIST_ADDR   0x114000
pid_t * const msg_list=(pid_t *)MSG_LIST_ADDR;
int sys_reg_serve(threadTp thread,msgT msg){
    msg_list[msg]=thread->pid;
    return  0;
}
/*
 *      有必要先阐明我的思想,否则无法继续进行了,服务进程注册服务进入睡眠状态,
 *  当内核接受到发送给服务进程的信号的时候,将该信息放入服务进程的消息队列,然后
 *  唤醒服务进程,服务完成后,服务进程将结果返回给系统,系统将结果返回给申请进程.
 *  如果服务进程没有信号要处理,转入睡眠.
 *
 */
int sys_send(msgT msg,int cmd){
    return 0;
}
int sys_receiv(msgT msg){
    return 0;
}
//extern pid_t fork(void);
